@ Developing Generic Software for Spacecraft Avionics 

A standardized functional model would facilitate cost-effective reuse of common 
software modules. 

NASA’s Jet Propulsion Laboratory, Pasadena, California 


A proposed approach to the develop- 
ment of software for spacecraft avionics 
is based partly on a concept of generic 
software that could be tailored to satisfy 
requirements for specific missions. The 
proposed approach would stand in con- 
trast to the conventional approach of 
first defining avionics requirements for 
a specific mission, then developing soft- 
ware specific to those requirements. 
The proposed approach might also be 
adaptable to programming computers 
that control and monitor other com- 
plex equipment systems that range in 
scale from automobiles to factories. 

The concept of a spacecraft avionics 
functional model (SAFM) is a major 
element of the proposed approach. An 
SAFM would be, essentially, a system- 
atic and hierarchical description of 
the functionality required of the 
avionics software (and hardware) for a 
given mission. Although the initial 
input information used to start the 
construction of an SAFM would typi- 
cally amount to a high-level descrip- 
tion, the SAFM would thereafter be 
decomposed to a low level. The result- 
ing low-level version of the model 
would be used to develop a set of 
generic requirements that could be 
expected to include a large fraction of 
all requirements for a large fraction of 
all missions. The generic require- 
ments would be used to develop soft- 
ware modules that could be included 
in, or excluded from, the final flight 
software to satisfy the requirements of 
a specific mission. 

By creating the opportunity to reuse 
common software modules on different 
missions, this approach would reduce 
the time, cost, and difficulty of develop- 
ing the software. In addition, a high de- 
gree of reuse is expected to lead to in- 
creased reliability. 

An SAFM would lend itself to any or 
all of the following five applications: 

• Education and Training 
The standard breakdown of function- 
ality would be helpful in education 
and professional training in the func- 
tions that occur aboard a typical 
spacecraft. 


• Systems Engineering 

The breakdown would proceed, 
more specifically, from functions to 
subfunctions to roles. Such a break- 
down would bring a standard tem- 
plate to part of the documentation of 
requirements. A standard template 
of this nature would increase the ef- 
ficiency and enhance the utility of 
software tools used to document the 
requirements, while remaining flexi- 
ble enough to be useful for a number 
of different projects. The standard 
template would, in effect, be a tex- 
tual version of the hierarchy of the 
SAFM, placed into the functional-re- 
quirements portion of the require- 
ments documentation for the space- 
craft in question. 

A key element of this approach is that 
at the breakdown-of-requirements stage 
of development of a given system, the 
requirements would be documented 
with respect to functionality but would 
not yet have been allocated to specific 
subsystems. It would still be possible, at 
this stage, to develop any of a number 
of different avionics architectures that 
would satisfy all the documented re- 
quirements. 

• Modeling of Resources 

The next step would be the estima- 
tion of the avionics resources used by 
each of the roles, and of how these 
avionics resources change with 
changes in the requirements of the 
roles. The next step would be to tab- 
ulate the resources required for each 
role, and then for each subfunction, 
in order to determine the resources 
used by each function. Once func- 
tions were assigned to subsystems, it 
would then be possible to determine 
the resources required by each sub- 
system. 

• Analysis, Tradeoffs, and Estimation of Costs 
If the modeling as described thus far 
were to be implemented with the 
help of an automated or semiauto- 
mated software tool, the next step 
would be to model a number of ar- 
chitectures and functional break- 
downs. The architectures would dif- 
fer in the functions assigned to 


different hardware subsystems. This 
modeling would yield estimates of 
such parameters as memory usage, 
data and processor instruction rates, 
bus bandwidth, power usage, mass, 
and volume. These estimates could 
be used to determine which of the 
proposed architectures would best 
satisfy mission requirements, which 
would be most flexible, and how the 
different architectures would use sys- 
tem resources. The final step in mod- 
eling would be to estimate the costs 
of the candidate avionics architec- 
tures. 

• Eunctional Standardization and Common- 
ality 

In an SAFM, the relationships among 
the roles within a subfunction would 
be the same. In other words, the 
roles would have constant functional 
contents, and their inputs and out- 
puts would stay constant, or nearly 
so. This implies that if a role were 
used in more than one mission, it 
may be possible to reuse, from one 
spacecraft to another, the software 
module that implements that role. If 
this were done for a few missions, a li- 
brary of software modules would 
soon be built up, making it possible 
for the next mission to limit itself to 
developing code for only those cor- 
responding functional modules that 
were new, that were characterized by 
significantly different requirements, 
or that had grown antiquated. 
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